home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d13 / patch.arc / INT9FX.EXE / KBFIX.DOC < prev    next >
Text File  |  1990-07-09  |  5KB  |  93 lines
  1.    KBFIX.DOC    09-Jul-1990
  2.  
  3.    A problem involving incorrect keyboard data has been reported by
  4.    several LANtastic user's. When using enhanced (101-key) keyboards
  5.    with NUM-lock on, a "Left-shift on" state occasionally becomes active
  6.    when no shift key is depressed. The state can be cleared by pressing
  7.    and releasing the left shift key. Also, on some machines, an enhanced
  8.    key (Arrows, Insert, Delete, Home, End, PageUp, PageDown) are
  9.    occassionally decoded as their numeric keypad NUMlocked equivalents,
  10.    e.g. "2", "4", "6", etc.
  11.  
  12.    The problem seems to stem from the fact that the enhanced keyboards
  13.    send a string of scan codes (4 scan codes when NUMlock is on) for
  14.    each press or release of the key. An E0 scan code precedes each of
  15.    the others, to indicate that the following scan code is to be interpreted
  16.    as "enhanced".
  17.  
  18.    These four scan code are sent in rapid succession to the PC motherboard.
  19.    As each is received, an IRQ1 is activated, which invokes the ISR for
  20.    INT 09H. This ISR is initially set to the BIOS keyboard handler,
  21.    although it is later re-hooked by resident drivers such as REDIR.
  22.    One of the first things the AT-BIOS handler does is to inhibit the
  23.    keyboard from sending further scan codes until processing of the one
  24.    causing the interrupt is complete.
  25.  
  26.    Unfortunately, before it does this, AT-BIOS executes an STI intruction,
  27.    allowing other interrupts (e.g., timer ticks) to interrupt the keyboard
  28.    ISR.
  29.  
  30.    Provided the interrupting timer tick ISR executes quickly, and control
  31.    returns to the keyboard handler before the scan code is replaced by
  32.    a new one, no harm is done. However, TSRs (such as REDIR) often hook
  33.    into the timer (08H) interrupt and may prolong its service time by
  34.    a substantial amount. If two scan codes come in quick succession
  35.    (as with the enhanced keys, which send E0 followed by the keycode),
  36.    then the first one (the E0 in this case) may be overwritten by the
  37.    second and be lost. Thus, the next scan code is interpreted as
  38.    a non-enhanced keystroke (a shift key or a numeric key).
  39.  
  40.    This problem would never occur if the BIOS would inhibit the keyboard
  41.    BEFORE it reenables interrupts. Unfortunately it doesn't, and the
  42.    BIOS cannot be changed.
  43.  
  44.    Four solutions to this problem have been written. The first, and by far
  45.    the most preferable one, is KBFLOW.EXE. This TSR hooks INT9, and as its
  46.    first action, inhibits the keyboard from sending more scan codes,
  47.    BEFORE it passes control to the next INT9 handler. Obviously this
  48.    TSR must be first in the chain of INT9 handlers to work effectively. To
  49.    ensure that it is always first in the chain, even when after other
  50.    programs hook INT9, it traps INT21h, functions 25h and 25h (get and
  51.    set interrupt vector) so the hooks are installed AFTER KBFLOW's
  52.    hooks. As a special case, to avoid interfering with SERVER's handling
  53.    of <CTRL-ALT-DEL>, the keyboard is NOT inhibited when this code is
  54.    received. KBFLOW takes ~350 bytes of resident RAM and will work in
  55.    most situations.
  56.  
  57.    An alternate, but less robust, solution is KBFIX.EXE. It should be run
  58.    in AUTOEXEC.BAT before any TSRs which hook INT 9 are loaded. It
  59.    searches through the MS-DOS INT 9 handler for DOS's hook into the BIOS
  60.    keyboard handler. When it is found, the hook is modified to point just
  61.    AFTER the offending STI instruction, thereby eliminating the possibility
  62.    of interrupt preemption until after the keyboard is disabled.
  63.    Unfortunately, it is necessary for a program of this nature to
  64.    take advantage of specific characteristics of DOS and BIOS. It has
  65.    been tried successfully on several 386 and 286 AT-BIOS implementations
  66.    with no problems. The program is smart enough NOT to make the
  67.    modification if a discrepancy is noted. Since the modification
  68.    is made within DOS, the program does not need to TSR, and no additional
  69.    memory is consumed. This solution is ineffective for lost scan
  70.    codes due to INT9 hooks which are added after KBFIX.
  71.  
  72.    If KBFIX.EXE cannot be used because INT9 is already hooked by a device
  73.    driver in CONFIG.SYS or the MSDOS is not compatible, the same effect
  74.    can be achieved by including KBDFIX.SYS as a device driver (ahead of
  75.    any other device drivers which hook INT 9) in CONFIG.SYS. The patch
  76.    will be applied directly to the BIOS INT 9 hook, and the driver
  77.    will not remain resident (no memory will be consumed).
  78.  
  79.    For specific BIOS implementations where KBFIX.EXE and KBDFIX.SYS will
  80.    not work, the INT9FIX.EXE utility was written. It loads as a TSR (288
  81.    resident bytes) and hooks the keyboard (09h) interrupt. Before passing
  82.    control to the BIOS keyboard handler, it masks IRQ0 (the timer) so the
  83.    keyboard ISR cannot be interrupted. When BIOS returns, it restores the
  84.    interrupt mask for IRQ0 to its original state. INT9FIX should normally 
  85.    be the FIRST TSR loaded which hooks INT9, so that timer interrupts are
  86.    masked for as short a time as possible. Some ill effects from using this
  87.    program have been noted -- since timer ticks are disabled,
  88.    operation of the Print-Screen key, the INT15 scan-code translation
  89.    hook, etc., may be affected in some software configurations.
  90.    
  91.     End  KBFIX.DOC
  92.  
  93.